Right now, I think the article creates a logical gap that has the potential to confuse readers.

The "in each thread" part implies there can be multiple event loops (via multithreading) in the same memory space. It's quite natural to then wonder how tasks will be associated with event loops when there are multiple event loops to choose from. And how you, the user, could manage which loop a task is assigned to. I see that as an easy way for the reader to be left in the dark, wondering.

I see two potential solutions. One is clarifying how tasks and event loops are paired in a multithreaded environment. The other, not mentioning threads at all. I don't feel that strongly either way. However, I do feel strongly that if we mention threads we need to explain how threads and multiple event loops interact.

Approach 1

:mod:!asyncio automatically associates tasks with the event loop for you.
Typically there's only one event loop, so that's quite straightforward.
It's uncommon, but some applications use multithreading and :mod:!asyncio
together, where there's one event loop per thread, stored in thread-local
storage.

Approach 2

No mention of threads. See the suggested changes in this PR.

• Issue: Potential confusion re: threading in asyncio HOWTO #138199

📚 Documentation preview 📚: https://cpython-previews--138200.org.readthedocs.build/